Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-atm-classic-ip-00.txt < prev next >

Wrap

Text File | 1993-06-16 | 24.6 KB | 620 lines

Network Working Group Mark Laubach Request for Comments: DRAFT Hewlett-Packard Laboratories Expires December 7, 1993 June 7, 1993 Classical IP and ARP over ATM Positioning note for Readers [This section to be removed after draft is reviewed a few times.] This document is the deliverable from an action item made at the Columbus IETF IP-over-ATM working group meeting on 3/28-3/30, 1993. In that meeting, the group enthusiastically (with applause) agreed to segment activities into two areas of focus: one is the treatment as ATM as a "wire replacement" for connecting IP host and routers, maintaining the current IP, ARP, and subnet architecture. This was dubbed the "classical" approach. The other focus area is the world where ATM subnets and peernets are widely deployed and globally connected, where the architecture of IP and ARP will need to change to take advantage of the features provided to it by this fully deployed ATM. It was felt that writing down the "Classical IP over ATM" specifications would be straightforward. This memo is a direct result of that action item and hopes to be the "starting block" for the efforts to come. Future memos will be forthcoming from the working group that update or obsolete this one as ATM becomes better defined and more fully deployed. The main differences between "classical" and "subnet/peernet" models are: Classical o One default maximum MTU size for the interface, consistent with current implementations. o Default LLC/SNAP encapsulation, with administrator allowed re- configuration. o IP destinations map to VC's via ARP and route lookups, consistent with current model. o ARP's stay within the LIS, current ARP architecture stays the same. Laubach [Page 1] DRAFT Classical IP and ARP over ATM May 1993 o One IP subnet used for many hosts/routers. A separate VC is used for each host/router pair, one subnet is used for all these VC's. o PVC's dominate, we're stuck with them for awhile. o Standard ATM signalling is non-existent. Subnet/Peernet: o MTU size negotiated per VC via ATM signalling, requires MTU size be separated from interface in protocol stack. o Encapsulation negotiated per VC via ATM signalling, requires common signalling to be implemented and globally available. o Any applications map to VC's, requires changes to TCP/UDP/IP to allow ports to map directly on to VC's o ARP's can go global, ARP architecture needs to change to support a robust global client/server model. o Differing QOS's will exist on a per application basis. The deployment of ATM into the internet community is beginning and will take several years to implement. During this period, we expect deployment to follow logical ("classical") IP subnet boundaries for the following reasons: o Administrators and managers of IP subnetworks will tend to initially follow the same models as they currently have deployed. The mindset of the community will change slowly over time as ATM increases its coverage and builds its credibility. o Policy administration practices rely on the security, access, routing, and filtering capability of IP Internet gateways: i.e. firewalls. ATM will not be allowed to "back-door" these mechanisms until ATM provides better management capability than the existing services and practices. The need for standardization for the "classical" approach is wide- spread and urgently needed. It is the intent of this position note to make the point that this memo should be moved quickly through the working group and into the draft standards process. Status of this Memo This document is an internet draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, Laubach [Page 2] DRAFT Classical IP and ARP over ATM May 1993 and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.src.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Abstract This memo describes an initial application of classical IP and ARP in an ATM network environment configured as a logical IP subnetwork, or "LIS" as described below and in [1]. This memo does not preclude the subsequent development of ATM technology into areas other than an LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This document considers only the application of ATM a as a direct replacement for the "wires" and local LAN segments connecting IP end-stations and routers. Issues raised by MAC level bridging are beyond the scope of this paper. 3. Acknowledgment This memo could not have come into being without the critical review from Jim Forster of Cisco Systems, Drew Perkins of FORE Systems, and Bryan Lyles and Steve Deering of XEROX PARC. The concepts and models presented in [1], written by Dave Piscitello and Joseph Lawrence, laid the structural groundwork for this work. This document could have not been completed without the expertise of the IP over ATM Working Group of the IETF. 4. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- this item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed Laubach [Page 3] DRAFT Classical IP and ARP over ATM May 1993 or ignored according to the needs of the implementor. 5. Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ARP requests and replies over ATM Adaptation Layer 5 (AAL5)[6]. Currently, ATM standards are being defined in the ATM-FORUM, the ITU-TSS (formally CCITT), and ANSI. ITU-TSS and ANSI are defining standards for public ATM networks, ATM-FORUM defines public and local aspects of ATM standardization. It is the intent of this document to follow ATM-FORUM standards for the use of Classical IP within local (non-public) networks. Initial deployment of ATM provides a LAN segment replacement for ethernet networks and as wire-replacement for dedicated public telecommunication lines between IP routers. In the former model, local IP routers with one or more ATM interfaces will connect islands of local ATM networks. ATM-FORUM compliant addressing will be used within these local ATM networks. In the latter model, public ATM networks will be used to connect IP routers, which in turn may or may not connect to local ATM networks. Public networks will use ITU-TSS and ANSI standards for addressing in ATM. ATM-FORUM compliant addressing cannot be guaranteed in public ATM networks. The characteristics and features of ATM networks are different than those found in LAN's: o ATM provides a virtual circuit switched environment. VC setup may be done on either a permanent (PVC) or dynamic (SVC) basis. SVC call management signalling is performed via Q.93B implementations [7]. o Data to be passed by a VC is segmented into 53 octet quantities called cells (5 octets of ATM header and 48 octets of data). ATM networks provide very low latency switching, high throughput, and the ability to multiplex VCs of differing quality of service. o Each VC carries a type which identifies a specific format for the exchange of protocol data units (PDU's). These formats are called ATM Adaptation Layers (AAL's) and are typed from 1 through 5. AAL5 specifies a packet format with a maximum size of 65K user data octets. Cells for an AAL5 PDU are transmitted first to last, the last cell indicating end of PDU. ATM standards guarantee that on a given VC AAL5 PDU's are not intermixed and that cell ordering is preserved end-to-end. o Multicast is not yet a conformance requirement of the ATM-FORUM. Laubach [Page 4] DRAFT Classical IP and ARP over ATM May 1993 o ATM hardware addresses are based on NSAP's. This memo describes the initial deployment of ATM within "classical" IP networks as a direct replacement for local area networks (ethernets) and for IP links which interconnect routers, either within or between administrative domains. "Classical" here refers to the treatment of the ATM host adapter as a networking interface to the IP protocol stack. This memo does not preclude the subsequent evolution of ATM networks as they become more globally deployed and interconnected and the evolution of TCP and IP to take advantage of these changes - these will be the subject of future documents. This memo does not address issues related to transparent data link layer interoperability. 6. IP Subnetwork Configuration This section describes the scenario for an ATM network that is configured with one or more logical IP subnetworks, LIS's. The scenario considers only directly connected IP hosts or routers. In the LIS scenario, each separate administrative entity configures its hosts and routers within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LIS's over the same ATM network. Hosts connected to ATM communicate directly to other hosts within the same LIS. Communication to hosts outside of the local LIS is provided via an IP router. This router would be a station attached to the ATM network that may have been configured as a member of two or more LIS's. This configuration results in a number of disjoint LIS's operating over the same ATM network. Hosts of differing IP subnets would communicate via an intermediate router even though a direct virtual circuit between the two hosts may be available over the ATM network. The requirements for IP member stations (hosts, routers) operating in an ATM LIS configuration are: o All members have the same IP network/subnet number. o All stations within an LIS are accessed directly over the ATM network. o All stations outside of the LIS are accessed via a router. o All members of an LIS must have a mechanism for resolving IP addresses to ATM addresses via ARP [4]. o All members within a LIS MUST be able to communicate with all Laubach [Page 5] DRAFT Classical IP and ARP over ATM May 1993 other members in the same LIS; i.e., the topology is fully meshed. There should be no administrative restrictions at the ATM level that prevent VC's from operating between all pair of stations. o If the ATM switching fabric supports hardware multicast addressing, then a group address MUST be configured whose membership is the set of all IP stations within the LIS. Furthermore, one VC SHALL be configured on each member station using this group address and dedicated for ARP queries/replies, and one VC SHALL be configured on each member station using this group address for encapsulated IP traffic (see section under Packet Format). The following list identifies a set of ATM specific parameters that MUST be implemented in each IP station which would connect to the ATM network. The parameter values MUST be user configurable: o ATM Hardware Address (atm$ha). The ATM individual address of the IP station. Each host must be configured to accept datagrams destined for this address o ATM ARP Request Address (atm$arp-req). The ATM hardware address (unicast or multicast) to which ARP requests are to be sent. Three cases are supported: 1. atm$arp-req is atm$ha, the local machine ATM hardware address. The local host may either consult its static ARP translation table directly, or support ARP queries by loopback internally or exter- nally via the ATM network. In the case of an external loopback, a VC is dedicated specifically for ARP queries and replies. 2. atm$arp-req is the ATM hardware unicast address of an individual ARP server located within the LIS. That server must have authorita- tive responsibility for resolving ARP requests all IP stations within the LIS. The VC's connecting IP stations to this ARP server are dedicated specifically for ARP queries and replies. 3. atm$arp-req is an ATM hardware group address. If the ATM switching fabric supports ATM hardware multicast, then a well known VC using the ATM group address local to the LIS is dedicated specifically for broadcast ARP queries and replies. The ARP query/reply service on all IP stations within the LIS MUST be reachable via this address. ATM hardware addresses are formatted as ATM-FORUM compliant NSAP's. [ref?] Laubach [Page 6] DRAFT Classical IP and ARP over ATM May 1993 ARP request and reply formats are discussed in the section on Address Resolution. It is RECOMMENDED that routers providing LIS functionality over the ATM network also support the ability to interconnect differing LIS's. Routers that wish to provide interconnection of differing LIS's MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/ subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical ATM interface that may have one or more individual ATM addresses. 7. Packet Format The default packet format for IP datagrams SHALL be the IEEE 802.2 LLC/SNAP format as described in [2]. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of encapsulation method on a per-VC basis. Signalling negotiations are beyond the scope of this document. 8. MTU Size The default MTU size for IP stations operating over the ATM network SHALL be 9180 octets. The LLC/SNAP header is 8 octets, therefore the maximum ATM AAL5 protocol service unit size will be 9188 octets. The minimum IP MTU size is 576 octets [8]. The LLC/SNAP header is 8 octets, therefore the minimum ATM AAL5 protocol data unit size will be 584 octets. This memo recognizes the future development of end-to-end signalling within ATM that will allow negotiation of MTU on a per-VC basis. End-to-end negotiations are beyond the scope of this document. 9. Address Resolution The dynamic mapping of 32-bit Internet addresses to ATM addresses SHALL be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [3]. Internet addresses are assigned independent of ATM addresses. Each host implementation MUST know its own internet address and ATM address and respond to Address Resolution requests appropriately. Hosts MUST also use ARP (either dynamically or via static table lookup) to map Internet addresses to ATM addresses when needed. Laubach [Page 7] DRAFT Classical IP and ARP over ATM May 1993 The ARP protocol has several fields that have the following format and values: Data: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type ar$hln 8 bits Octet length of hardware address (n) ar$pln 8 bits Octet length of protocol address (m) ar$op 16 bits Operation code (request or reply) ar$sha noctets source hardware address ar$spa moctets source protocol address ar$tha noctets target hardware address ar$tpa moctets target protocol address Where: ar$hrd - assigned to NSAP address family and is nn decimal (0x00nn) [4]. ar$pro - see Assigned Numbers for protocol type number for the protocol using ARP. (IP is 0x0800). ar$hln - length of the larger of the source or target hardware NSAP address length. ar$pln - length in bytes of the protocol address field. For IP ar$pln is 4. ar$op - 1 for request and 2 for reply ar$sha - source NSAP address. ar$tha - target NSAP address. The ATM hardware addresses in ARP packets (ar$sha, ar$tha) SHALL be ATM-FORUM specified NSAP addresses.[ref?] The same NSAP encoding SHALL be used within an LIS and replies will use the same encoding as queries. For example, NSAP's may encode IEEE 48-bit MAC addresses or may encode E.164 addresses. Within the LIS either IEEE MAC or E.164 hardware addresses may be used but not both. ARP packets are to be encoded in AAL5 PDU's using LLC/SNAP encapsulation. The format of the AAL5 CPCS-SDU payload field for routed non-ISO PDU's is: Laubach [Page 8] DRAFT Classical IP and ARP over ATM May 1993 Payload Format for Routed non-ISO PDU's +------------------------------+ | LLC 0xAA-AA-03 | +------------------------------+ | OUI 0x00-00-00 | +------------------------------+ | Ethertype 0x08-06 | +------------------------------+ | | | ARP Packet | | | +------------------------------+ The LLC value of 0xAA-AA-03 (3 bytes) indicates the presence of a SNAP header. The OUI value of 0x00-00-00 (3 bytes) indicates that the following two-bytes is an ethertype. The Ethertype value of 0x08-06 (2 bytes) indicates ARP [4]. The total size of the LLC/SNAP header is 8-bytes fixed length. This aligns the start of the ARP packet on a 64-bit boundary relative to the start of the AAL5 SDU. The LLC/SNAP encapsulation for ARP presented here is consistent with the treatment of multiprotocol encapsulation of IP over ATM AAL5 as specified in [2] and in the format of ARP over IEEE 802 networks as specified in [5]. Traditionally, ARP requests are broadcast to all directly connected IP stations within a LIS. It is conceivable in the future that larger scaled ATM networks may "broadcast" ARP requests to destinations outside the originating LIS, perhaps even globally; issues raised by broadcasting outside the LIS or by a global ARP mechanism are beyond the scope of this document. 10. IP Broadcast Address ATM hardware multicast is not yet a conformance requirement of the ATM-FORUM. As such, there is no consistent facility in ATM switches for hardware multicast addressing. The following scenarios apply to the multicast and non-multicast situations: 1. ATM multicast available: if the switch fabric connecting the host ATM interface supports multicast, then the Internet broadcast address (the address on that network with a host part of all binary ones) MUST map to an ATM group address that includes all Laubach [Page 9] DRAFT Classical IP and ARP over ATM May 1993 IP stations within the LIS. 2. No ATM multicast support: the Internet broadcast address MUST map to atm$arp-req, and atm$arp-req MUST either map to the local IP host ATM hardware address or the ATM hardware address of an ARP server located within the LIS. In either case, encapsulated IP packets sent to the IP broadcast address may be received on the ARP query VC. This requires that IP packets sent to the IP broadcast address use LLC/SNAP encoding and that all stations examine the value of ethertype in the LLC/SNAP header and process IP versus ARP accordingly on all packets received on this VC. 11. IP Multicast Address IP multicast address mapping to ATM group addresses are not discussed in this memo. 12. Security Security issues are not discussed in this memo. This memo recognizes the future development of ATM and IP facilities for authenticated call setup, authenticated end-to-end application knowledge, and data encryption as being required services for globally connected ATM networks. These future security facilities and their use by IP networks are beyond the scope of this document. 13. Open Issues [This section to be removed after draft is reviewed a few times.] There are some open issues: o A proposal was put before the Internet Assigned Numbers Authority to approve a request to create an ARP hardware type of "NSAP family address". IANA has not responded as of this date. My hopes are that we can get an ARP type created now that will cover NSAPs for all time. o Well known ATM hardware address(es) for ARP servers? It would be very handy if we came up with a set of well known ATM addresses for ARP services. We should probably have well-known PVC numbers for a non-SVC environment also. o Should this require that Interim Local Management Interface (ILMI) be used to obtain the ATM address network prefix from the Laubach [Page 10] DRAFT Classical IP and ARP over ATM May 1993 network? o We need to be able to reference ATM-FORUM documents within this memo, are these publicly released? If yes, what are the references? REFERENCES [1] Piscitello, D., and Lawrence, J., "IP and ARP over the SMDS Service", RFC1209, USC/Information Sciences Institute, March 1991. [2] Heinanen, Juha, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", work in progress, IETF IP over ATM Working Group, February 1993. [3] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982. [4] Reynolds, J., and Postel, J., "Assigned Numbers", RFC1340, USC/ Information Sciences Institute, July 1992. [5] Postel, J., and Reynolds, J., "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC1042, USC/Information Sciences Institute, February 1988. [6] CCITT, "Draft Recommendation I.363", CCITT Study Group XVIII, Geneva, 19-29 January 1993. [7] CCITT, "Draft text for Q.93B", CCITT Study Group XI, 23 September - 2 October 1992. [8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC1122, USC/Information Sciences Institute, October 1989. [Need ATM-FORUM references.] Authors' Addresses Mark Laubach Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto, CA 94304 Phone: 415.857.3513 FAX: 415.857.8526 EMail: laubach@hpl.hp.com Laubach [Page 11]